[Previous] [Next] [Index]
[Thread]
Re: Java "security holes'
There is nothing new in Java particularly.
It is stripped-down C++ compiled into a souped-up p-code. The interpreter
(or virtual machine) for said p-code is integrated into the Netscape
browser although not in the most popular platform: MS Windows 3.1 and DOS.
It is the ready availability and ease of use that seem to be the cause of
panic. It does not change anything in IP or DNS. BTW, what happens if you
d/l the applet from a group of servers faking being one server? Each time
you connect you get a different IP address for the same name. NCSA does this.
On Sun, 10 Mar
1996, Dan Stromberg wrote:
> Date: Sun, 10 Mar 1996 11:00:22 -0800
> From: Dan Stromberg <strombrg@hydra.acs.uci.edu>
> To: Dana Hudes <dhudes@panix.com>
> Cc: www-security@ns2.rutgers.edu
> Subject: Re: Java "security holes'
>
> While I tend to feel that people scream overloud about "java problems",
> it isn't really overrestrictive to insist that an applet only talk to
> the server from which it was loaded.
>
> EG, if the server is S, the machine on which the applet is running is A,
> and the applet decides it would be a good thing to talk to some other
> machine, O - then A can pass a message to S along the lines of "send
> some data to O".
>
> That way the machines an applet can access, are only those that S would
> have been able to access, anyway. Even if O is behind a firewall,
> nothing is given away.
>
> Then again, if you _want_ to be able to access O, and it's behind a
> firewall, you need a copy of that applet on a server behind your
> firewall...
>
> ...which puts http proxies in an interesting light, if they're behind a
> firewall.
>
> IMO, java technology has outpaced IP's (and DNS's) ability to keep pace.
>
> Dana Hudes wrote:
> >
> > I am new to Java. I understand some folks are afraid of the ability to
> > have a d/l applet proceed to contact any host on the net . BUt applets
> > cannot access local files. The Java concept is the diskless workstation
> > which has Netscape or other Java browser in EEPROM (along with an O/S and
> > network stack, which of course does not have to be TCP/IP as long as
> > sockets are supported) and maybe an Object Request Broker in there as well
> > (a few meg of EEPROM all told!).
> >
> > Restricting outgoing connections (or incoming!) to the server you got the
> > applet from is a heavy restriction of utility to the legitimate applets.
> > You prohibit two stations on the net from talking, you eliminate data
> > sharing between peers. One cannot have a multiplayer game. One cannot
> > contact a certificate server . One cannot access a database server that
> > is different from the web server.
> >
> > The most secure environment is disconnected from the outside world.
> > THa'ts the line you're headed down.
>
References: